這幾天，我們已經學習了如何使用SonarQube跟Jenkins整合，使得我們開發的程式碼有質素上的保證。但其實除此以外，要保障我們開發的軟體亦需要顧及一個非常重要的因素，就是開源軟體引用的問題。

開源軟體的安全性

使用開源軟體有一個非常好的優勢，就是使得整個開發流程變得快捷簡單。因為一些簡單的功能可以直接引用開源套件/軟體的功能，省卻了開發團隊大量的開發時間。但以我個人的經驗為例，很多我接觸過的例子，在引用套件的時候，只側重於考慮所需要的功能，而並没有定立一個很明確的標準，來決定如何選擇合適的開源套件。結果就是開發過程中為軟體引用了很多不同的套件，但又没有仔細去了解到底相關的套件是否有潛在的安全性問題。

加上某一些套件在市場上比較受歡迎，引用的次數可能成千上萬。甚至一些大型的企業亦會依賴相關的開源套件去進行企業軟件的開發。因此這一類比較多人使用的開源套件，就會很容易吸引到黑客成為攻擊目標。黑客們只需要找到相關套件的漏洞，那麼大量引用了相關套件而開發的軟體，都會繼承了相關的漏洞。黑客們就可以利用這個漏洞去對相關的服務造成破壞，或是取得不法的利益，使相關的企業造成無可估計的損失。

以最近一個影響比較廣泛，Apache Log4j的Log4Shell漏洞為例。Log4Shell這個漏洞是一個Java Naming and Directory Interface (JNDI)的注入漏洞。利用這個漏洞，可以讓黑客們遙距執行代碼。黑客們可以使用你的系統資源去挖掘加密貨幣，或者進行網絡阻斷攻擊，又或是搜集取得你系統上的資料等。由於Log4j是一個Java開發者常用的日誌記錄套件，單單在2021年8月到11月這4個月期間，此套件的下載量合計就超過了2.86億次。可想而知這個漏洞在威脅性上及影響範圍上都算得上是非常嚴重。

CVE跟NVD

既然開源軟體可能有潛在的風險或漏洞，那麼我們如何才能得知相關的套件是否安全呢?

這個時候，我們必須提及一個重要東西，那就是CVE。CVE全稱是Common Vulnerabilities and Exposures，意指通用漏洞披露，是一個與資訊安全有關的資料庫。該資料庫收集了各種資訊安全的弱點及漏洞，然後給予對應的編號，讓公眾可以很方便就能查閱。

每一個漏洞都會給予一個專屬對應的CVE編號(以上述Log4Shell漏洞為例，其對應編號為CVE-2021-44228)。 編號的格式為CVE-YYYY-NNNN，YYYY為西元紀年，NNNN為流水號，少於4位數時前面補0。當我們需要查找相關的套件資料時，我們可以到CVE資料庫中搜尋對應的套件漏洞的資料。

而當每一個漏洞發布到CVE Dictionary後，美國國家標準暨技術研究院(NIST)轄下的資訊科技實驗室(ITL)中的國家漏洞資料庫(NVD)內的工作人員，就會對相關的漏洞進行分析。分析的結果會按照通用漏洞評分系統(CVSS)給予評分、通用缺陷列表(CWE)進行分類、通用列舉平台(CPE)編配識碼別等，然後收錄到資料庫中。開發人員可以通過NVD，取得相關套件的漏洞的分析結果，以了解其安全風險。

開源套件管理系統

然而，即使有了以上的資料庫，我們總不可能以手動的方式，每日查看專案中的套件有否對應到公布的漏洞。因此我們便需要利用工具，去幫我們比對專案中的套件，是否有對應的漏洞。而今天介紹的，就是由開放式Web應用程式安全專案(OWASP)機構支持的套件分析平台，Dependency Track。

Dependency Track除了支援上述的NVD整合外，亦支援整合Sonartype OSS Index、GitHub Advisories、VulnDB等漏洞資料庫。Dependency Track會定期從整合了的資料庫中，自動取得最新的漏洞分析並進行更新。

用戶可以利用CycloneDX去產生出開發中的程式的軟體物料清單(Software Bill of Materials，簡稱SBOM)，然後上載到Dependency Track。上載後的SBOM檔案會跟整合了的資料庫進行對比，然後得出專案的漏洞列表以及對應的風險指數。

除此以外，用戶亦可以在Dependency Track中設定不同的政策。當某一個專案違反了特定的政策時，亦可以從管理介面中取得相關的報告。

值得一提的是，相關的政策除了可以以漏洞風險作為指標去釐定之外，Dependency Track亦可以以套件的授權許可作為指標。這個做法亦可以避免誤用一些需要授權才可以使用的套件，減少法律上被控告的風險。

小結

今天我們先了解開源軟件供應鏈安全的重要性。明天，我們就會學習如何安裝Dependency Track。

題外話

終於第10天了，1/3的路程，感謝大家這十天的支持!!